hi @pavanjoshi914 , there were three test failing initaially, the recent push i made fixed two of them, so presently only one test is failing, and that's for SitePreferences, for ths particular test, i think the test is not really efficient and that is why it fails,

i noticed the test added for "set new budget" might be a bit too tightly coupled to the internal formatting behavior especially the exact number and order of calls to mockGetFormattedInCurrency as each digit is typed (2 → 25 → 250).

This makes the test a bit fragile and implementation-dependent, it could start failing if, for instance, the input handling is optimized (e.g. with debouncing or batching), even if the feature still behaves correctly for users.

It might be more robust to:

• Assert that the formatting function is called with the final value (250) for both "BTC" and "USD".

• Optionally verify a few key calls, but not every intermediate one.

• Focus more on the final visible value or onEdit being triggered, rather than the total call count.

Interestingly, the initial version of the test (with mockGetFiatValue) already leaned in this direction. it focused more on verifying that the final value was passed and that the right callbacks were triggered, without overasserting internal details. It just needs updating to reflect the current DualCurrencyField implementation and the mockGetFormattedInCurrency function.

That way the test better reflects actual user-facing correctness without being overly strict on internals.

i can rewrite the test to better illustrate what i’m suggesting if editing the test is welcomed.

yup if it makes sense

yup if it makes sense

alright, i would do that.

I refactored the effect that syncs the external value prop with the internal input state in DualCurrencyField to improve clarity, performance, and correctness. The previous logic was doing multiple conversions and comparisons that often led to redundant state updates and unnecessary re-renders. It also made the control flow harder to follow

so now, we track the last seen value and only run conversions when there's a meaningful change. I also ensure the input value is only updated if the final rendered value would actually change, avoiding unnecessary React updates.

This PR got messy after a rebase/force-push — I’ve opened a clean version here: #3395